CD ROM Paradise Collection 4/CD ROM Paradise Collection 4 1995 Nov.iso/hamradio/sgp4_pl2.zip/SGP4-PLB.DOC

Text File | 1992-10-01 | 12KB | 202 lines

                              Documentation for
                             NORAD SGP4/SDP4 Units

                                 Developed by
                                 Dr TS Kelso

                                 Version 2.50
                                1992 October 01

Copyright (C) 1992.  All rights reserved.


PURPOSE

The enclosed Pascal source code implements the NORAD SGP4/SDP4 orbital models
for use with the standard two-line orbital element sets to determine earth-
centered inertial (ECI) and topocentric coordinates of earth-orbiting objects.
This code implements both the near-earth and deep-space portions of the NORAD
SGP4 orbital model.  These units are designed to make the development of
programs based on the NORAD orbital models straightforward and standardized.


INTRODUCTION

In order to properly determine the position of any earth-orbiting object using
the standard NORAD two-line element sets, it is necessary that the proper
orbital model be used.  Since the observations taken by NORAD for each earth-
orbiting object are reduced to orbital elements using the SGP4 (Simplified
General Perturbations) model, the SGP4 model *must* be used to get the most
accurate determination possible of an object's position and velocity.  The
primary reason for this requirement is that each orbital model handles
perturbations (due to atmospheric drag, solar and lunar gravitational effects,
irregularities of the earth's gravitational field, etc.) in a different
manner.  The NORAD two-line element sets incorporate these perturbations using
the SGP4 orbital model and that model is required to accurately reconstruct
the magnitudes of these effects.

The SGP4 orbital model takes into account perturbations due to atmospheric
drag (based on a static, non-rotating, spherically-symmetric atmosphere whose
density can be described by a power law), fourth-order zonal geopotential
harmonics (J2, J3, and J4), spin-orbit resonance effects for synchronous and
semi-synchronous orbits, and solar and lunar gravitational effects to first
order.  The two portions of the SGP4 model are SGP4 (for objects in orbits
with periods less than 225 minutes) and SDP4 (for objects in orbits greater
than or equal to 225 minutes).  The reason for breaking the model into two
parts is that for low-earth orbits the effects of spin-orbit resonance and
lunar and solar gravity are not significant.  This result allows the
development of an analytical model (SGP4) for determining an object's position
and velocity, thereby reducing the computational burden.  For deep-space
orbits, a semi-analytical model (SDP4) is required.

Models which implement the older SGP model should be accurate for low-earth
orbits but really won't be adequate for deep-space objects, particularly those
in resonance with the geopotential.


COMPUTER IMPLEMENTATION

The enclosed Pascal source code was developed in Turbo Pascal Version 6.0 to
fully implement the NORAD SGP4 orbital model.  There are now twelve units
provided:

     SGP4SDP4     Full implementation of NORAD SGP4/SDP4 models
     SGP_OBS      Observer-dependent routines for calculating topocentric
                  information
     MINMAX       Minimum/maximum functions
     SGP_MATH     Various trigonometric and mathematical routines
     SGP_TIME     Time-based routines for converting among time systems
     SGP_INIT     Code and variables needed to initialize SGP4SDP4
     SGP_INTF     Interface between SGP4SDP4 and SGP_CONV (and some special-
                  purpose programs)
     SGP_CONV     Routines for converting two-line data and SGP4 state vectors
     SGP_IN       Routines to simplify input of data (with error checking)
     SGP_OUT      Routines for outputting program results in standard formats
     SOLAR        Routines for calculating the position of the sun and whether
                  a satellite is in earth umbral eclipse
     SUPPORT      General support routines for machine-dependent features

These units are structured to make development of software as simple as
possible and to reduce the time needed for validating results.  A certain
amount of the development is also tailored toward the development of a similar
set of units in C, which is now underway.  A more complete description of
these Pascal units is included in SGP4-PLB.ITF.

Of the units provided, the most complex is the implementation of the NORAD
orbital models (SGP4SDP4).  The development of this unit was done to follow as
closely as possible the implementation contained in Spacetrack Report Number
3, "Models for Propagation of NORAD Element Sets," (a copy of the LaTeX
documentation and complete FORTRAN source code is available on this system).
No attempt has been made at this point to optimize the code to run faster.  A
future release will provide a more streamlined implementation.  To ensure the
validity of these units, no changes should be made to the units themselves
which have been extensively tested and validated.  LaTeX documentation to
support this validation should be available on this system soon (look for
SGP4-VAL.TEX).

A test program (SGP4TEST.PAS) is included to implement the sample cases
included in the Spacetrack Report Number 3 documentation.  It should provide a
reasonably good idea of how to use these Turbo Pascal units.  To determine an
object's position and velocity, the object's two-line orbital element set is
read into the array {sat_data} [Note:  Variable names will be enclosed within
braces to set them apart in this document].  A call is then made to the
procedure Convert_Satellite_Data passing the satellite's index {satnumber}.
In the call to this procedure, a determination is automatically made as to
whether the object is in a near-earth or deep-space orbit; the result is
returned in {ideep}.  If {ideep} is 0, then the object is in a near-earth
orbit; if {ideep} is 1, it is in a deep-space orbit.  A call is then made to
either SGP4 or SDP4 depending on the value of {ideep}.

The time passed in this call, {tsince}, represents the time since (before or
after) the satellite epoch in the two-line element set.  The four-dimensional
vectors {pos} and {vel} are returned containing the x, y, and z ECI
coordinates (referenced to the true equator and mean equinox of date) and
vector magnitude of the object's position and velocity, respectively, at the
specified time.  Units are earth radii and earth radii per minute,
respectively; appropriate conversions must be made to get the proper units (as
demonstrated in the test program using Convert_Sat_State).  The variable
{iflag} is used internally for keeping track of initialization conditions for
the deep-space portion of the model.

Running this test program should provide results quite close to those provided
in the Spacetrack Report Number 3 documentation.  The minor differences that
do occur are due to two primary reasons.  The first is the result of
differences in the internal precision of the FORTRAN compiler used to generate
the report and that of the Turbo Pascal compiler.  The second is due to the
choice to implement a consistent numerical precision in the Turbo Pascal code.
Examination of the FORTRAN source code will reveal inconsistent use of single
and double-precision variables and trigonometric functions; the Turbo Pascal
code uses double-precision variables and functions throughout.

Because it is not very straightforward to perform calls to the SGP4 units
based on the time since each satellite's element set epoch, a procedure is
also provided which interfaces between a standard time system and the SGP4 and
SDP4 calls.  This procedure, SGP, requires only that the user pass the Julian
Date of interest; the procedure Julian_Date_of_Epoch converts from a date in
the format used in the two-line element set to a Julian Date.  The SGP call
also takes care of making the determination of whether the object is in a
near-earth or deep-space orbit and calls the appropriate model.  The SGP_TIME
unit contains these procedures as well as routines to convert Julian Dates to
more recognizable time formats.

The main advantage of using the Julian Date in SGP is that there is no problem
calculating the time interval between the time of interest and the satellite
element set epoch, regardless of whether this interval spans the beginning of
a year.  There is also a function to convert Julian Dates to calendar dates
(Calendar_Date) of the form "1992 Jan 30."  Epoch_Time transforms the Julian
Dates to the form used in the two-line element sets.

The test program SGP4TST2.PAS gives an example implementation of this
approach.  It is designed to produce the same results as SGP4TEST.PAS.  The
main difference is that the Julian Date is calculated to be the time of the
epoch for each element set and then the offset (in minutes) is added.  Be sure
to note that times outside the units are now all in *days* not in minutes (as
they are inside the units).


CONCLUSION

These Turbo Pascal units should make it easy to implement the official NORAD
orbital models in developing any number of applications.  It is now very
straightforward to select input files (of satellite and observer data) and
time conditions (with full error checking) and output data ranging from
spacecraft ECI position and velocity to spacecraft ground tracks (latitude,
longitude, and altitude) to look angles (azimuth, elevation, range, and range
rate) to right ascension and declination.  Each of these outputs uses the WGS
'72 geoid (nonspherical) and takes into account atmospheric refraction, where
appropriate.  These results can be easily output as text or incorporated into
advanced graphical applications.

For a full-blown example of how to implement these functions, look for the
application TrakStar/SGP4, also available on this system.  It allows output
for up to 250 satellites (or element sets for a single satellite) in the form
of spacecraft ECI position and velocity, spacecraft ground tracks (latitude,
longitude, and altitude), look angles (azimuth, elevation, range, and range
rate), and right ascension and declination.  A separate data file is created
for each object/element set -- a great tool for all sorts of analyses.

Future releases of these units will include routines to efficiently determine
crossing phenomena (e.g., satellite rise/set, sun rise/set, and satellite
entry into/exit from earth eclipse) and local optima (e.g., closest approach).
And, of course, the existing units will be converted to C with an eye toward
portability.

In a continuing effort to promote standardization of orbital calculations, I
will endeavor to continue to improve this package and will gratefully accept
user feedback or contributions to this effort.

                                       - Dr TS Kelso
                                         Internet:  [e-mail]
                                         anonymous ftp at archive.afit.af.mil
                                           in the directory pub/space

                                         SYSOP, Celestial BBS
                                         513/427-0674 (modem)
                                         Operating 24 hours/day
                                         No parity, 8 data bits, 1 stop bit
                                         300, 1200, 2400, 4800, and 9600 bps
                                         v.32/32bis, v.42/42bis

                                         2340 Raider Drive
                                         Fairborn, OH, USA  45324-2001